這是我第一次建置 Custom GPT 的心路歷程，以及把小成果當作鐵人賽的分享故事
很高興可以在這裡讀到我文章的大家 ：）
下午兩點，會議室的白板上寫著「會員專屬服務需求討論」。
需求方 PM 的同事 A 先開口：「我們想做一個會員專屬服務，讓符合資格的客戶可以選擇兌換喜歡的服務。」
系統分析師（SA）皺了一下眉：「請問會員的定義是什麼？是所有持卡客戶，還是要再篩選？」
A 想了一下：「應該是高價值客戶...吧?」
「高價值是用消費金額還是用會員等級判斷？」
「呃……我再回去確認。」
SA 維持微笑：「沒問題。那選擇服務的時候，可以選幾項？選完可以改嗎？如果服務名額滿了怎麼辦？」
A 開始翻筆記。SA 看著對方翻第三頁時，腦中默默打開了那個熟悉的 Excel：「需求未明確項目追蹤表」，已經有 47 列了。
A 抬起頭：「這個……我們再開一次會討論好了。」
會議結束。30 分鐘裡，真正討論到「系統怎麼做」的時間是零。SA 走回座位，看了看牆上的 sprint board，輕輕嘆了一口氣。下午本來要排估算的，現在大概排不到了。
我相信你不陌生。我在企業內部負責產品工作多年，看過太多這樣的會議，而且我也曾經是那個翻筆記的同事 A。痛定思痛之後，我把這類會議的卡點歸納成三個。
對需求方PM 來說，他們腦袋裡有一個模糊的願景：「讓客戶體驗變好」、「降低客服進線」、「跟競品看齊」。但要把這個願景轉成一份結構化的需求文件，難度大概等於要一個從沒寫過論文的人交一篇博士論文。
他們腦袋裡其實有東西，只是不知道哪些東西該被寫出來。
一份典型的需求單據通常會問這些欄位：
| 欄位 | 需求方PM 第一次填的內容 | 開發團隊看到時的內心 OS |
|---|---|---|
| 目標使用者 | 「客戶」 | （...全人類嗎？） |
| 解決的問題 | 「現有流程不方便」 | （哪個流程？哪一步？） |
| 成功指標 | 「希望大家都喜歡用」 | （這要怎麼量測？問卷？） |
| 例外情境 | （空白） | （這格是 NPE 嗎...） |
| 上線時間 | 「越快越好」 | （越快越好等於昨天） |
每一格的答案都不算錯，但每一格都缺乏可以被開發的具體性。SA 拿到這份文件，第一個動作就是約一場會議來追問。會議裡再追問的結果，往往只是把「客戶」改成「會員」，把「越快越好」改成「Q3 上線」，還是不夠精準。三個月後 sprint 跑到一半，需求方PM 突然說「對了，我們不是說的是『活躍會員』嗎？」此時離 demo 還剩四天。
空白頁從來不是好的引導工具，沒有人會看著一張白紙，自動想起「啊我要描述使用者旅程的第 3 步」這種事。
對 SA 來說，需求釐清會議的前 30 分鐘，幾乎都在做兩件事：
我曾經偷偷觀察過 SA 朋友的會議時間分配（純屬不科學的個人統計，誤差大概 ±20%）：
| 環節 | 時間佔比 |
|---|---|
| 釐清「你到底想做什麼」 | 40% |
| 確認「使用者怎麼用」 | 25% |
| 討論「例外怎麼處理」 | 15% |
| 真正討論「系統怎麼設計」 | 15% |
| 行政事項（時程、誰負責、誰請假） | 5% |
80% 的時間，SA 都在做應該由需求方PM 在會前完成的工作。
更微妙的是，SA 的追問經常被需求方PM 解讀為「找麻煩」。需求方PM 心裡 OS：「我就是覺得這樣比較好啊，為什麼要問這麼多？」SA 心裡 OS：「你不告訴我細節，我下午要怎麼跟工程師交代？」兩邊都不是不想合作，純粹是溝通成本被默默轉嫁到了 SA 身上。SA 下班後常常需要喝一杯，加班只是表象，真正累的是腦袋還在繼續開那場會議。
我親眼看過 SA 在會議中打字打到一半，停下來、深吸一口氣、再打，那一秒鐘他大概在心裡跟自己說「冷靜，他不是故意的」。職業修養很重要。
第三個痛點是術語牆。
SA 會問：「這個功能需要做 idempotent 嗎？」需求方PM 一臉問號，內心 OS：「這是什麼，新的咖啡品牌嗎？」
SA 換個說法：「使用者重複點兩次送出按鈕，會不會造成重複扣款？」需求方PM：「啊，這個我沒想過。」
這跟需求方PM 沒水準無關，重點是他們腦袋裡根本沒有「重複送出」這個維度。在他們的世界裡，使用者就是「正常使用」，誰會點兩次？（事實是：手機卡頓、網路不穩、手指出汗、按鈕被嬰兒玩到，每天都在發生。）
開發團隊腦袋裡有一個內建的「邊界情境清單」：登入過期、API 超時、網路斷線、權限不足、資料衝突、Race Condition、Time Zone bug……這份清單從來沒有被寫出來給需求方PM 看過。它存在於工程師的偏頭痛、半夜三點被 PagerDuty 叫起來的記憶、以及前公司那個讓他學到血淋淋教訓的 Post-mortem 文件裡。
於是每次需求討論，都是 SA 拿著腦袋裡的隱形清單一條一條丟出來，需求方PM 一條一條回「沒想過」。會議開到一半，需求方PM 開始懷疑自己「是不是哪裡做得不對」，SA 開始懷疑「這個需求是不是根本沒準備好」。最後雙方一起懷疑人生。
這三個痛點看起來各自獨立，但往下挖，其實長在同一條根上：需求方跟開發根本不在同一條船上。
現在的合作模式比較像發包：需求方丟一張單過來，開發端低頭收件、埋頭做。問題是，需求方自己常常也說不清楚到底要什麼、什麼叫「做得更好」；而開發端只能照單全收，一直做、一直交，卻不知道自己做出來的東西好不好、到底為了解決什麼而做。兩邊各自在霧裡走，誰也看不見對方那一半的盤子。
這是一件很糟的事。需求單位跟開發應該是同一個團隊，一起對「要解決的問題」負責，而不是一邊指使、一邊接單。一份好的需求釐清，要做的不只是把單寫清楚，是先把兩邊拉回同一條船上：講清楚「為什麼做、做完算成功的長相是什麼」，讓開發端知道自己在為什麼而做，也讓需求方知道自己到底在要什麼。
當然... 工具改變不了組織的協作關係，那是 KPI 怎麼算、SA 有沒有被授權提早介入、兩邊是不是同一個老闆的事，一個 GPT 碰不到。它能做的，是把這個斷裂裡「需求方輸入品質」這一段補起來：讓送到 SA 面前的東西，不再是一張連自己都沒想清楚的單。這一段顧好，不等於兩邊就變成一個團隊，但至少讓他們有機會站在同一個基礎上對話，而不是從「請問會員的定義」重來一遍。
過去這段時間，我有過很多嘗試：
所有現有工具都假設需求方PM 知道自己要什麼，只是不知道怎麼寫。但實際上，他們最大的問題是不知道自己該想什麼。
工具沒幫忙引導思考，只負責盛裝結果。空盤子永遠盛不出滿漢全席。
所以我在 ChatGPT 上做了一個 Custom GPT，名字叫「鼠勾以」。它不是 PRD 生成器，也不是 SA 替代品（SA 朋友們，放心，你甩不掉親愛的需求單位的）。它是一個會：
它服務的對象很明確：那些懂自己業務、卻不習慣把業務翻成開發語言的需求方PM。這裡有個前提要講白，工具補的是「翻譯」這一關，不是「教人懂業務」。需求方PM 對自己的領域往往比工程師熟得多，缺的只是把腦袋裡的東西，組織成工程師看得懂的規格。如果一個人連自己的業務都搞不清楚，那是選人跟訓練的事，不是工具能救的。讓懂業務的人在會議前先把該想的想過一次，會議時 SA 就不用再從「請問會員的定義」開始問了。
寫在前頭（系列定調）：這個系列測試於 2026 年 5 月，場景是一間大型、相對保守、受監管，而且多數同仁對 AI 還不算熟悉的企業。底下所有的判斷與選擇，都綁定這個時空與背景，不宣稱放諸四海皆準。換一個時代、換一種組織，答案很可能不一樣。
接下來 30 天，我會從這四個面向拆解這套工具：
| 階段 | 內容 |
|---|---|
| 起源篇 | 為什麼要做、競品比較、設計目標 |
| 架構篇 | Custom GPT 構成、知識庫分工、Instructions 取捨、設計關聯 |
| 機制篇 | 溝通原則、七大區塊、評分系統、進階機制 |
| 產出篇 | PRD 模板、工時估算、安全規則、回顧 |
老實說，鼠勾以是我第一次認真建一個比較複雜的 Custom GPT。以前頂多寫些丟一段 prompt 就上工的小工具，這次第一次碰到要拆十幾份知識庫、卡 Instructions 字數上限、還要管一堆檔案互相牽動這種規模。所以這 30 天與其說是教學，比較像是把我自己邊摸邊做的過程攤出來：哪裡一開始想錯、哪裡打掉重做、最後怎麼長成這麼一個還能用的小東西。一邊記心路歷程，一邊把這點小成果當作鐵人賽的成果分享。
如果你也在企業裡負責產品、需求釐清、或是常常被需求方PM 跟工程團隊夾在中間（我懂），這個系列可能對你有用。如果你對「怎麼設計一個會主動挑戰使用者的 GPT」感興趣，這個系列也會把每個設計細節拆解給你看。
明天 Day 2，我會從一場我親身經歷的失敗會議講起，分享我決定動手做這個工具的起源，而不是繼續寫更精緻的 PRD 模板，或者繼續每天下班後喝一杯QQ。
這是 iThome 鐵人賽系列文章。明天見。
iThome鐵人賽
看影片追技術